人能自律，但前提是有法律，同理，軟體架構和 Style Guide 就是程式中的法律，不從者，該死愛的小手。
https://github.com/raywenderlich/swift-style-guide#extending-lifetime
這篇涵蓋了大部分 Swift 開發過程中，會遇到的 Style 選擇時機，而且其最終選擇都很理性，也因此是一個客觀、適合盲從的 Style Guide。
關於 Naming 的部分，Ray Wenderlich 有寫明，我們應該參考 Swift API Design Guidelines，我的想法是，既來之則安之，既然選擇 Swift 程式語言，在合理的情況下，就遵從 Swift 本身的設計。
但是其中有一點我覺得不合理，在 Ray Wenderlich 的 Style Guide 中，有寫到：
Each extension should be set off with a // MARK: - comment to keep things well-organized.
我認為要能夠快速定位每個物件，是 IDE 的工作，尤其是在型別如此清楚的程式語言下，IDE 應該更容易做到這件事，我們就不用在一一去寫 //MARK: - 協助定位，工程師的腦袋是記不住東西的，不能要求工程師寫程式的同時還要記得寫這樣的註解。
Ray Wenderlich 選擇了兩個空白，如果在 Swift 語法每個都熱熱等的狀況下，選擇用兩個空白很合理。
此 Style Guide 不止提供一個程式碼的「樣式」參考，也涵蓋了很多程式設計上的「最佳實踐」，我認為這樣的 Style Guide 是相當客觀理性，不是隨便遵從一個人的喜好而產生的，因此這個 Style Guide 可以列入考慮。
這個 Style Guide 已經在 2017-11-09 結束營業，已經停止維護的話，就不列入考慮，但是我們可以稍微閱讀一下，鑑往知來。
三大法條造就今天的 Swift：
以上主要來自 Swift API Guidelines 並加上個人習慣用語。
其實三大法條已經能清晰闡述 Swift 的設計理念，下列則是一些相對有趣、特別的 Guidelines。
x.makeIterator()。入了王朝，能不祀奉國王？
有了律法，就能建構王朝，而王朝的成敗，取決於宮殿的規劃，千萬不能把國王的寢室放在茅廁的旁邊。
https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52
大致上看完作者對於各框架（MVC、MVP、MVVM、VIPER）的分析與看法，作者的角度很客觀，總結的部分觀念也很正確，沒有「正確的框架」，只有「最適合的框架」。
由作者文章看起來，VIPER 似乎是彈性最高的架構，但是對於剛起步的小專案來說，VIPER 反而過於複雜，為了達到 VIPER 的設計，反而拖慢了開發速度，因此我認為，在套用軟體框架時，應該針對當下的程式碼做評估，並「適當」地將未來功能加入考量。
因此，從這將近三十天積極開發 Money Mom 的經驗來看，我認為現階段使用 MVVM 最適合。
不用 VIPER 的原因，是因為目前還沒有複雜的使用路徑，整個架構、功能很單純，複雜的是各項界面上的小元件互動。所以應該思考如何讓各個小元件之間，彼此獨立，不要有過度的相依性，並減少程式碼的重複，就能有效改善目前的程式碼，並繼續推進功能開發。
最後評估一下，其實基本上 Style Guide 的部分就暫時依照 Ray Wenderlich、Swift API Guidelines 走，在軟體架構上，則是依照 MVVM 的心法做一些調整，最終的目的都是一樣的，就是讓目前的程式碼更易讀、更好維護、更好開發功能。
其實在網路上搜尋 iOS best practice 之類的關鍵字，就會出現很多常見的「名詞」，比方說各種架構、奇技淫巧、經驗談，這類的文章在各個語言都會出現，不過我在學習新的工具時，還是會瞭解一下，畢竟每個工具都會有各自「習慣」。
最重要的是，不管學習工具還是閱讀論文，要想辦法學到「心法」，也就是要瞭解「為什麼」，為什麼要用 MVP？為什麼要 VIPER？為什麼……？
因為每篇文章，都有一個「背景」，不是每個人遇到的問題都一模一樣，因此我們要學習其心法，然後透過這樣的「心法」基礎，去瞭解、嘗試解決我們所遇到的問題，才不會淪為工具人，被工具利用。
參考資料：
iThome鐵人賽
看影片追技術